Follow-up update for this PR:

Since the previous revision, I added a few safety/completeness improvements around the new Reality proxy-protocol support:

Newly added changes

1. Robust PROXY header writes

   • Changed header writing to use a full write path instead of a single conn.Write(...).
   • This avoids short-write edge cases that could otherwise send an incomplete PROXY header to the backend.

2. Stricter address-family handling

   • PROXY v1/v2 now only encode:
     • IPv4 when both source/destination are IPv4
     • IPv6 when both source/destination are IPv6
   • Mixed-family cases now fail explicitly instead of falling through into an unintended encoding path.

3. Expanded unit tests

   • Added IPv6 test coverage for both PROXY v1 and PROXY v2
   • Added mixed IPv4/IPv6 family mismatch tests
   • Added config validation coverage for invalid proxy-protocol values

4. Documentation clarification

   • Updated config examples to clarify that proxy-protocol passes the original source/destination address information to the backend
   • Noted that the backend must support Proxy Protocol

Current status summary

This PR adds proxy-protocol support to Reality inbound backend forwarding.

Behavior

• New Reality inbound option: proxy-protocol
  • 0: disabled
  • 1: send PROXY protocol v1 header
  • 2: send PROXY protocol v2 header

Implementation

• Adds ProxyProtocol to Reality inbound config and runtime config
• Validates accepted values at build time
• Captures accepted inbound connection addresses:
  • source: client remote address
  • destination: listener local address
• Passes these through context into the Reality backend dial path
• Writes the PROXY header to the backend connection before normal payload forwarding

Scope

• Reality inbound/backend path only
• No outbound behavior changes

Test status

• Focused listener/reality tests pass
• Unit coverage now includes:
  • disabled mode
  • v1/v2 IPv4 encoding
  • v1/v2 IPv6 encoding
  • missing address context
  • invalid version
  • invalid config value
  • mixed-family rejection

This should make the feature safer and easier to reason about in edge cases.